IBIS Macromodel Task Group Meeting date: 28 July 2020 Members (asterisk for those attending): Achronix Semiconductor Hansel Dsilva ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis * Jared James Google: * Zhiping Yang Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao Radek Biernacki Ming Yan * Todd Bermensolo * Rui Yang Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Randy to send out a modified version of the BIRD207 draft (Component_Name and Signal_Name proposal). - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the July 21 meeting. Michael moved to approve the minutes. Walter seconded the motion. There were no objections. ------------- New Discussion: Component_Name and Signal_Name Reserved Parameters, BIRD207 draft: Arpad shared the new BIRD draft Randy had sent out. Arpad noted that the example specifying a Default had been removed, as was agreed upon at last week's meeting. Michael asked why the [Component] name and signal_name are being passed into the model instead of Pin name. To answer, Walter illustrated an expected use case for the BIRD. Suppose one is modeling a memory, in this case a x8 with DQ0 through DQ7. You're using the clock-forwarding BIRD (BIRD204), and there's a clock tree in the component, and the delay in the tree may be different for each DQ. By passing in the signal_name, the model can then apply the different internal DQ to DQS delay for each DQ. On top of that, imagine the IBIS file has ten different [Component]s. If the internal delay for a given DQ is the same for all the [Component]s, then the signal_name would be sufficient. However, the internal delays might be different for each [Component], so having the [Component] name and signal_name helps in that case. Walter said he thought signal_name is likely to be a requirement for the model, but [Component] name might be optional. However, if the user is doing a pre- layout simulation, then the tool might not know which DQ either, and it could leave both Component_Name and Signal_Name empty. In that case, the model will know that the tool doesn't have the unique information. Arpad noted that the proposal states that both Component_Name and Signal_Name are required if either one exists. Curtis said this meant that both must appear in the .ami file if either appears, but the tool is free to pass "" in for either value if it doesn't have the information. Bob asked why put "placeholder" as the Value in the examples? When would that be passed into the model? Arpad said the proposal states that this value will never be sent to the model. The tool replaces it with the name of the Component or signal_name, or it passes "" if it does not know that information. Bob asked how the tool could not know this information, since it's right in the IBIS file. Curtis said Randy was trying to support tools that might offer simulations based only on the .ami file and executable model, and not the full Component and Pin info from the IBIS file. Michael said this proposal assumes the executable model knows all the information about the delays, and it will figure it all out. He said that he'd always thought the tool would be the one that figured out the delays. So how could the executable model contain this information? Arpad clarified that the executable model knows about the on-die differences (e.g. DQ-DQS delay) for different DQ lines on the Component. This proposal lets the executable model use a look up table based on the signal and Component names, rather than have to create a separate executable model for each DQ. Ambrish agreed that the assumption is that the same executable model could be used for all the DQs (or even multiple Components). Walter added that the EDA tool only knows the DQ-DQS skew up to the pad of the memory device. This proposal takes the perspective of the memory model maker. A skew is generated between DQ and DQS at the controller, and then there's additional delay in the interconnect, and all of that is the tool's responsibility. But this proposal is limited to helping the model maker keep track of differences internal to the memory module. Michael said this answered his question. Arpad asked if the group thought this was ready to submit as a BIRD. Bob moved to recommend that Randy submit the BIRD to the Open Forum. Curtis seconded. There were no objections. DDR5 DQ Write Protocol: Walter noted that BIRD201.1 "Back-channel Statistical Optimization" had been approved at the last Open Forum meeting. Walter shared his presentation "DDR5_DQ_Write_Protocol (BIRD147/201)". - slide 2: General BCI Flow (BIRD147/201) Walter reviewed a block diagram of the BCI components and flow. He noted that this proposal applies equally to statistical optimization (BIRD201.1) and time- domain optimization (BIRD147.6). The protocol describes the information that is passed between the Tx and Rx. The EDA tool does not have to process this information in any way. It simply passes the BCI_parameters_in and BCI_parameters_out back and forth to the Tx and Rx in the case of BIRD201.1, or the information is written directly to a file with no EDA tool intervention in the case of BIRD147.6. Walter noted that there is no proposed protocol for a DDR5 Read cycle, because in that case there is no need for back-channel optimization. The memory is the Tx on a Read cycle, and the Rx (controller) handles everything on its end since the Tx isn't programmable. For the DDR5 Write cycle, the controller is the Tx and it wants to decide what the Rx equalization settings should be and what its own equalization settings should be, if it has any. How does it go about doing that? - slide 3: JEDEC and Generic protocols Walter noted that JEDEC standards have the Tx telling the Rx tap indices to use (register values) and a requested BER. His JEDEC protocol supports this. For his Generic protocol, which supports cases where we don't have a JEDEC compliant Tx and or Rx, the Tx tells the Rx the actual tap coefficients and a requested BER. In actual hardware the Tx can't request a BER of 1e-16, as this would take too long. Typically it expects to run 1k to 10k UI, for a practical BER of 1e-3 or 1e-4. The Tx requests the setup, the Rx says it complied or says how close it was able to come to honoring the request, and the Rx returns a metric. The metrics proposed are eye width, eye height, and area of the eye (not width * height) at a given BER, and COM. - slide 4: What the Tx tells the Rx each iteration - JEDEC protocol - BER for the metrics - Gain register setting - VrefDQ register setting - DFE indices and register settings - Generic protocol - same information, but passing real values instead of integral register settings. - slide 5: What the Rx tells the Tx each iteration The Rx takes what it was told to do, tries to do it, and responds. For example, it might have been asked to provide a metric at BER 1e-5, but if the eye was closed at that contour it might return the metric at the 1e-3 BER contour. - JEDEC protocol - Return the BER used - Return the gain value corresponding to the register setting the Tx requested - Return the VrefDQ value - Return the DFE indices and the DFE coefficients used - Must return the metrics - Generic protocol - Return the BER used - Return the gain register setting that gives the gain closest to that requested - Return the gain itself - Return the VrefDQ register setting that gives the VrefDQ closest to that requested - Return the VrefDQ value - Return the requested DFE indices (if they were supported) - Return the DFE coefficients - Return the same metrics - slide 6: Metrics - optPulseMetric() One can generate the metrics from an IR. The Rx has an IR available. Many tools can take an IR and generate a statistical eye, but their methods might vary and the results could be slightly different. Walter proposed using a specific calculation, as defined by the optPulseMetric() function in MATLAB. He suggested that if IBIS were to approve this, they could put the algorithm for that function in the public domain. - slide 7: Next Steps - IBIS has left it unspecified how BCI protocols are: - published - approved - amended Walter noted that this presentation amounted to a first step in publishing this protocol. Approval would have to come from IBIS. Amending a protocol has not yet been considered. Walter said he would like to work out the protocol in ATM and then notify the Open Forum and see what it decides to do in terms of approving a protocol or merely posting it. Walter said his goal was to propose a common protocol that memory and controller vendors would agree to support. Bob said one option would be for IBIS to approve it and give it a name such as: IBIS__. Walter agreed. Zhiping asked if this proposal is only for the simulation or also for the hardware. Walter said the protocol just defines what the Tx and Rx AMI models exchange during simulation. It allows the person creating the Tx model to know how to communicate with the Rx model. The algorithm the Tx model uses can be the same as the one in the hardware or its own special algorithm. It's possible the algorithm developed for the model could be what is ultimately compiled to create the controller firmware itself. - Walter: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Randy to submit the Component_Name and Signal_Name BIRD draft to the Open Forum as an official BIRD. ------------- Next meeting: 04 August 2020 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives